This PR does not work with escaped dynamic imports which is one of the reasons we reverted #13269. For example if you prepend the following content in the vite.config.js in playground/define, the config fails to load.

const dynImport = (id) => {
  return import(id)
}
globalThis.__STRINGIFIED_OBJ__ = 'foo'
const result = await dynImport('./commonjs-dep/index.js')
console.log('result', result)

To fix this, we need to replace dynamic imports with something else and resolve it on our side like #17894 did. I wonder if we can avoid the global function by exposing an internal function from dist/index.js as we have the file in this PR's case.

We currently already not have good support for escaped dynamic imports. We bundle all code from different files to a single file, so that means the source files that're within the same directory as vite.config.js will only work right now. This PR does break that they will no longer work, but I think it's rare for someone to do this.

Usually it's also more common for escaped dynamic imports on dependencies rather than paths, and it'll still work in this PR.

Checking the repro in #13730 which caused the revert, it seems to still work well with this PR.

Ah, that's true. Sounds good to me to try it out.

/ecosystem-ci run

📝 Ran ecosystem CI on ce23bcc: Open

✅ analogjs, astro, histoire, ladle, laravel, marko, nuxt, previewjs, quasar, qwik, rakkas, storybook, unocss, vite-environment-examples, vite-plugin-pwa, vite-plugin-react, vite-plugin-react-swc, vite-plugin-svelte, vite-plugin-vue, vite-setup-catalogue, vitepress, vuepress

Open in Stackblitz

pnpm add https://pkg.pr.new/vite@18509

commit: a591a79

I couldn't think of a case where this would break, but I haven't really tested this more robustly either yet.

this doesn't really help in cases where node_modules are not writable

I couldn't think of a case where this would break, but I haven't really tested this more robustly either yet.

this doesn't really help in cases where node_modules are not writable

I am using NIX to manage NodeJS packages, which results in node_modules not being writable.

Upgrading to Vite v6+ results in Vite no longer being able to start because of that.

See also: #18839

node_modules not being writable.

Readonly node_modules will cause issues with not just vite. Many tools write temp files to node_modules/.cache, it's a community standard.

I just wish that vite would also use .cache instead of this .vite-temp. If vite were to use the linked module, one would be able to override with env var CACHE_DIR, which would be a workaround.

Upgrading to 6.0.3 broke my build today as I also use a readonly node_modules directory. Wouldn't /tmp and the Windows equivalent be the most appropriate places for a temp directory? Or something configurable at least? Out of 1000s of packages Vite is the only one I can think of that tries to write to node_modules and other unexpected locations. I would strongly prefer that packages not do this.

Update from the future: #18637 introduces a new option to run Vite without writing a bundled config file